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We  also  identify  the  problem  of  relation  fragmentation  which  occurs 
when  a ouery  is  executed  by  several  processors  in  parallel  and  develop 
a technique  for  estimating  the  optimal  number  of  processors  to  compress 
a relation  so  that  the  execution  time  of  the  entire  query  is  minimized. 
These  results  appear  to  be  applicable  to  all  database  machines  which 
employ  parallel  processing  techniques  to  enhance  query  execution. 


Significance  and  Explanation 


A multiprocessor  database  machine  is  being  implemented  at 
the  University  of  Wisconsin  which  has  a unique  structure  that 
includes  the  following  two  features:  First,  the  number  of 
processors  assigned  to  execute  a query  can  be  dynamically 
determined  on  the  basis  of  the  priority  and  nature  of  the  query. 
The  second  feature  is  that  the  number  of  processors  assigned  to 
a query  can  be  increased  or  decreased  during  the  execution  of 
the  query.  The  technique  used  to  implement  these  features  is 
discussed . 

When  more  than  one  processor  executes  a query,  different 
pieces  of  the  answer  will  be  distributed  between  the  different 
processors.  This  relation  fragmentation  leads  to  inefficiencies 
for  which  a solution  is  given. 
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ABSTRACT 


In  this  paper  query  organization,  execution,  and  optimiza- 
tion in  the  database  machine  DIRECT  are  discussed.  We  demon- 
strate that  the  use  of  a monitor  for  each  relation  referenced  by 
a query  along  with  the  use  of  the  NEXT_PAGE  construct  permits  the 
DIRECT  back-end  controller  to  assign  a query  to  any  number  of 
processors  for  execution.  Furthermore,  these  constructs  also 
permit  the  controller  to  balance  the  load  in  the  back-end  by 
dynamically  adjusting  how  many  processors  are  assigned  to  each 
executing  query. 

We  also  identify  the  problem  of  relation  fragmentation  which 
occurs  when  a query  is  executed  by  several  processors  in  parallel 
and  develop  a technique  for  estimating  the  optimal  number  of  pro- 
cessors to  compress  a relation  so  that  the  execution  time  of  the 
entire  query  is  minimized.  These  results  appear  to  be  applicable 
to  all  database  machines  which  employ  parallel  processing  tech- 
niques to  enhance  query  execution. 


1.0  Introduction 


This  paoer  discusses  query  organization,  execution,  and  oo- 
timization  in  DIRECT.  DIRECT  is  a mult iDr ocessor  organization 
for  supporting  relational  database  management  systems  which  is 
being  implemented  at  the  University  of  Wisconsin.  DIRECT  can 
support  the  simultaneous  execution  of  relational  algebra  queries 
from  different  users  in  addition  to  parallel  processing  of  single 
queries.  Section  1.1  contains  an  overview  of  DIRECT's  organiza- 
tion. More  details  can  be  found  in  [1,2], 

One  feature  which  differentiates  DIRECT  from  the  other  data- 
base machines  which  have  been  proposed  is  its  relational  algebra 
query  organization  and  execution.  As  will  be  demonstrated  in 
Sections  2.0,  3.0,  and  4.0,  the  unique  structure  of  DIRECT 
queries  results  in  the  following  two  features.  First,  the  number 
of  processors  assigned  to  execute  a query  can  be  dynamically 
determined  based  on  the  priority  of  the  query,  the  type  and 
number  of  relational  algebra  operations  included  in  the  query, 
and  the  size  of  the  relations  referenced.  The  second  effect  of 
our  organization  is  that  the  number  of  processors  assigned  to  a 
query  can  be  increased  or  decreased  during  the  execution  of  the 
query. 

Section  5.0  presents  a discussion  of  a problem  which  has 
been  ignored  by  all  previous  database  machine  designers.  This 
problem  arises  when  more  than  one  processor  is  used  to  select 
from  a relation  those  tuples  which  satisfy  a search  condition. 
We  call  this  problem  "relation  fragmentation".  To  illustrate  we 
will  use  the  "restriction"  operator.  Assume  that  the  relation 
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boinq  "restricted”  is  divided  into  fixed  size  pages  (tracks  in 
RAP  [3,4])  and  that  thei e is  one  processor  pet  page  (track). 

Then,  when  the  search  condition  is  applied  by  all  processors  in 
parallel  to  the  relation,  each  processor  will  produce  a subset  of 
the  new  relation.  This  new  relation  will  contain  those  tuples 
which  satisfy  the  restriction.  In  DIRECT  each  processor  will 
produce  some  fraction  of  a oaqe  of  the  new  relation.  In  RAP, 
each  processor  will  "mark”  those  tuples  on  its  track  which  satis- 
fy the  search  condition.  (For  a discusion  of  mark  bits  versus 
temporary  relations  see  [1,2].)  If  this  new  relation  represents 
the  results  of  the  query,  this  fragmentation  is  not  a significant 
problem.  However , if  this  new  relation  is  to  be  used  by  a subse- 
quent operator  (such  as  a join)  in  the  query,  then  the  degree  of 
relation  fragmentation  will  have  a significant  impact  on  the  per- 
formance of  this  operator.  This  performance  degredation  will  oc- 
cur because  any  subsequent  operator  which  uses  the  fragmented  re- 
lation  as  an  operand  will  have  to  read  all  of  the  partially 
filled  pages  (tracks)  in  order  to  access  all  the  tuples  of  the 
intermediate  relation.  RAP  has  no  choice  but  to  suffer  the  ef- 

| 

feet  of  this  fragmentation  and,  as  a consequence,  RAP  executes 
joins  with  about  the  same  performance  as  a single  conventional 
processor  [5].  In  Section  5.0,  we  introduce  the  concept  of 
compression  as  a technique  for  reducing  the  degree  of  relation 
fragmentation.  Then,  we  analvze  the  cost  of  compression  in  order 
to  calculate  the  optimal  number  of  processors  to  perform  the 
compression  so  that  the  execution  time  of  the  entire  query  is 


minimized. 
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1.1  DIRECT  Systems  Architecture 

DIRECT  consists  of  six  main  comoonents:  a host  processor,  a 
back-end  controller,  a set  of  query  processors,  a set  of  CCD 
memory  modules  which  are  used  as  Dseudo-associative  memories,  an 
interconnection  matrix  between  the  set  of  query  processors  and 
the  set  of  CCD  memory  modules,  and  one  or  more  mass  storaqe  dev- 
ices. A diagram  of  these  components  and  their  interconnections 
can  be  found  in  Figure  1.1. 

The  host  processor,  a PDP  11/45  running  the  UNIX  operating 
system,  handles  all  communications  with  the  users.  A user  who 


wishes  to  use  DIRECT  will  log  onto  a modified  version  of  INGRES 
[6]  and  then  proceed  in  the  normal  manner.  However,  when  the  user 
wishes  to  execute  a query,  INGRES  will  compile  the  querv  into  a 
tree  of  relational  algebra  operations  called  a "query  packet"  and 
then  send  it  to  the  back-end  for  execution. 

The  back-end  controller  is  a PDP  11/40.  It  is  responsible 
for  interacting  with  the  host  processor  and  controlling  the  query 
processors.  After  the  back-end  controller  receives  a query  pack- 
et from  the  host,  it  determines  the  number  of  query  processors 
that  should  be  assigned  to  execute  the  packet.  If  the  relations 
which  are  referenced  by  the  query  packet  are  not  currently  in  the 
associative  memory,  the  back-end  controller  will  page  portions  of 
them  in  before  distributing  the  query  packet  to  the  query  proces- 
sors selected. 

Each  query  processor  is  a PDP  11/03  with  28K  words  memory. 
The  function  of  each  query  processor  is  to  execute  query  packets 
assigned  by  the  back-end  controller. 


USER 
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Since  DIRECT  has  a MI MD  architecture,  it  is  caoable  of  sup- 
porting both  intra  and  inter-query  concurrency.  To  facilitate 
the  support  of  intra-querv  concui rency,  relations  are  divided 
into  fixed  size  pages.  Each  query  processor,  assigned  bv  the  con- 
troller to  execute  a query  packet,  will  "associatively"  search  a 
subset  of  each  relation  referenced  in  the  packet.  When  a query 
processor  finishes  examining  one  cage  of  a relation,  it  makes  a 
request  to  the  back-end  controller  for  the  address  of  the  next 
page  it  should  examine.  Since  several  query  processors,  each  ex- 
ecuting the  same  query,  can  request  the  "next  page"  of  the  same 
relation  simultaneously,  the  controller  operations  must  be  indi- 
visible. This  will  insure  that  each  of  the  query  processors  will 
be  given  a different  page  to  examine.  After  receiving  the  ad- 
dress of  the  page  from  the  controller,  the  query  processor  must 
be  able  to  rapidly  switch  to  that  cage.  Details  of  an  intercon- 
nection matrix  which  permits  this  can  be  found  in  [1,2]. 

To  facilitate  support  of  inter-query  concurrency,  the  asso- 
ciative memory  and  interconnection  matrix  must  permit  two  query 
processors,  each  executing  different  queries,  to  search  the  same 
page  of  a common  relation  simultaneously.  By  eliminating  dupli- 
cate copies  of  a relation,  we  not  only  reduce  memory  requirements 
but,  more  importantly,  we  eliminate  the  problem  of  updating  mul- 
tiple copies  of  a relation  without  sacrificing  performance. 


2.0  Query  Packet  Format 


The  types  of  query  pac<ets  which  are  received  by  the  back- 
end controller  can  be  divided  into  two  classes  based  on  informa- 
tion contained  in  the  Dacket  header.  Class  I contains  those  com- 
mands which  manipulate  system  catalogues  (e.g.  CREATUB) . Execu- 
tion of  these  commands  generally  involves  addition  or  deletion  of 
information  in  one  or  more  tables  which  are  maintained  bv  the 
back-end  controller  and  does  not  involve  any  query  processors. 
For  more  details  the  reader  should  see  [1,2].  Class  II  contains 
those  queries  which  will  be  executed  by  a collection  of  query 
processors.  In  this  section,  we  will  discuss  the  structure  of 
this  class  of  query  packets. 

Each  Class  II  ouery  packet  is  structured  as  a tree  (see  Fig- 
ure 2.1).  The  leaf  nodes  of  this  tree  correspond  to  relations 
referenced  in  the  query.  Each  non-leaf  node  is  either  a rela- 
tional algebra  operator  or  an  intermediate  relation.  The  set  of 
operators  supported  include  the  traditional  operators  such  as 
JOIN,  PROJECT,  RESTRICT,  UNION,  INTERSECTION,  and  DIFFERENCE  as 
well  as  aggregrate  operators  such  as  MAX,  MIN,  COUNT,  etc. 


Figure  2.1 


One  of  the  unique  featut es  of  DIRECT  is  the  general  struc- 
ture which  is  common  to  all  the  relational  algebra  operators  sup- 
ported. This  structure,  as  we  will  demonstrate  in  Section  4.1, 
permits  a query  packet  to  be  assigned  to  any  number  of  query  pro- 
cessors without  modifying  the  packet.  Fur  thermor e , this  operator 
structure  permits  additional  auerv  processors  to  be  dynamically 
assigned  to  execute  a packet  during  execution  of  the  packet  by 
other  query  processors.  We  will  conclude  this  section  with  an 
example  of  a simple  INGRES  query  and  the  corresponding  query 
packet.  This  example  will  be  used  in  Section  4.1  to  illustrate 
how  our  flexible  query  processor  assignment  scheme  is  implement- 
ed . 

Given  the  SUPPLIER  relation  shown  in  Figure  2.2  and  the 
INGRES  query  to  find  the  names  of  all  suppliers  in  N.Y.: 

RETRIEVE  (SUPPLIER. NAME)  WHERE  SUPPLIER .CITY  = "N.Y." 

Then,  the  compiled  query  packet  for  this  query  has  the  structure 
shown  in  Example  2.1.  Note  that  the  packet  never  asks  for  an  ex- 
plicit page  of  a relation.  Instead,  the  next  paae  of  the  rela- 
tion is  always  requested.  This  structure,  when  combined  with  a 
monitor  for  every  relation  referenced  by  a packet,  permits  us  to 
dynamically  assign  query  processors  to  executing  query  packets 
( see  Sect  ion  4.1). 

SUPPLIER  Relation 


Figure  2.2 


CITYQPKT 

LOCK (SUPPLIER, READ) 

CREATE  NYSUPPLIERS  /*  create  result  relation  */ 

DO  FOREVER 
BEGIN 

- ASK  BACK-END  CONTROLLER  (BEC)  FOR  THE  NEXT_PAGE  OF  RELA- 
TION SUPPLIER 

- WAIT  FOR  THE  BEC  TO  RETURN  THE  PAGE  FRAME  NUMBER 

- IF  THE  BEC  RETURNS  "END  OF  RELATION"  QUIT  AND  SIGNAL  DONE 
OTHERWISE 

- READ  NEXT  PAGE  OF  RELATION  SUPPLIER  INTO  LOCAL  MEMORY 
FROM  THE  PAGE  FRAME 

- EXAMINE  ALL  TUPLES  READ  IN 

- COPY  EACH  TUPLE  THAT  SATISFIES  THE  RESTRICTION 
SUPPLIER. CITY  = "N.Y."  INTO  A LOCAL  PAGE  BUFFER 

- WHEN  THE  BUFFER  IS  FULL 

- ASK  (BEC)  FOR  THE  NEXT_PAGE  OF  RELATION 
NYSUPPLIERS 

- WAIT  FOR  BEC  TO  RETURN  A PF# 

- WRITE  BUFFER  INTO  PF# 

END 

UNLOCK (SUPPLIER) 

Example  2.1 


3.0  Query  Processor  Allocation 


We  are  currently  investigating  two  alternative  approaches 
for  allocating  query  processors  to  a query  packet  when  the  back- 
end controller  decides  to  execute  the  packet.  These  approaches 
are  termed  the  fixed  allocation  approach  and  the  dataflow  machine 
approach.  In  the  fixed  allocation  approach  the  QPA  process  exam- 
ines the  packet  and  attempts  to  estimate  an  "optimal"  query  pro- 
cessor allocation  for  this  packet.  By  optimal  we  mean  that  as- 
signment of  more  than  the  optimal  number  of  query  processors  to 
the  packet  will  not  decrease  the  execution  time  for  the  packet. 
For  example,  assume  that  the  query  packet  joins  relation  A and 
relation  B and  that  relation  A is  N paqes  long  and  relation  B is 
M pages  long.  Then,  the  optimal  query  processor  allocation  for 
this  packet  is  MAX(M,N).  This  allocation  will  reauire  MIN(M,N) 


time  units  where  a time  unit  is  the  time  required  to  join  one 
paqe  of  A with  one  oaqe  of  3.  In  chis  example,  the  optimal  allo- 
cation is  truly  ootimal.  However,  consider  the  packet  which 
first  joins  A and  B and  then  joins  the  resultinq  relation  with  C. 
Since  it  is  impossible  to  predict  the  size  of  A join  3,  it  is  im- 
possible to  determine  exactly  how  many  query  processors  should  be 
assigned.  We  plan  to  investigate  several  heuristics  for  deter- 
mining the  "optimal"  query  processor  allocation. 

In  the  dataflow  machine  approach  to  query  processor  alloca- 
tion, only  simple  relational  algebra  operations  (JOINS,  RESTRIC- 
TIONS, PROJECTIONS,  etc.)  are  assigned  to  the  query  processors 
and  not  complete  query  packets.  This  eliminates  the  difficult 
task  of  estimating  an  "optimal"  query  processor  allocation  for  an 
entire  packet.  Instead,  an  exact  value  for  each  step  in  the 
packet  can  be  determined.  In  addition  to  increasing  query  pro- 
cessor utilization,  this  approach  should  also  decrease  page 
traffic  in  DIRECT.  This  should  occur  because  as  soon  as  a page 
of  "A  join  3"  is  produced,  another  query  processor  can  beqin 
joining  it  with  C.  Hence,  the  likelihood  that  the  page  will  be 
paged  out  is  reduced.  We  are  currently  comparing  this  data  flow 
machine  approach  with  the  standard  QPA  scheme  to  determine  the 
effect  of  each  on  system  throughput  in  DIRECT. 
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4.0  CCD  Memory  Management 

The  function  of  the  CCD  memory  management  process  in  the 
back-end  controller  is  three  fold: 

- Respond  to  a NEXT_PAGE  request  from  a query  processor 

- Respond  to  a GET^PAGE  request  from  a query  processor 

- Schedule  the  movement  of  pages  of  relations  between  CCD  memory 
page  frames  and  mass  storage  as  the  result  of  NEXT_PAGE  and 
GET_PAGE  operations. 

4.1  The  NEXT__PAGE  Operation 

The  form  of  a NEXT_PAGE  request  is: 

NEXT_PAGE (QPKTifRELj ,QPk) 

This  is  a request  from  query  processor  k which  is  executing  query 
packet  i for  the  next  page  of  relation  j.  The  resulting  action 
is  for  the  BEC  to  send  the  page  frame  number  which  contains  the 
next  page  of  relation  j to  query  processor  k.  A page  fault  can 
occur  if  the  required  page  is  not  in  some  CCD  page  frame.  Han- 
dling of  page  faults  is  the  same  for  both  the  NEXT_PAGE  and 
GET_PAGE  operations  and  is  discussed  in  Section  4.3. 

Since  a auery  packet  can  be  assigned  to  any  number  of  query 
processors,  there  must  be  a way  to  prevent  two  simultaneous 
NEXT_PAGE  requests  from  different  query  processors  executing  the 
same  packet  from  getting  the  same  page.  This  is  handled  by  the 
use  of  the  Query  Packet  Task  Table  which  is  shown  in  Fiqure  4.1. 
The  Query  Packet  Task  Table  has  one  entry  for  each  instance  of 
each  relation  referenced  by  each  executing  query.  Associated 
with  each  entry  is  a monitor [7]  which  controls  access  to  the 
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table  entry.  Initially,  the  currency  pointer  for  the  relation  is 
set  to  zero. 


QUERY  PACKET  TASK  TABLE 


QPKT  # 

RELNAME 

CURRENCY 

POINTER 

POINTER  TO 
PAGE  TABLE 

FOR  RELATION 

CITYQPKT 

SUPPLIER 

i 

CITYQPKT 

NYSUPPLIERS 

j 

Figure  4.1 

As  an  example,  assume  that  query  processor  allocation  ini- 
tially assigns  the  CITYQPKT  query  in  Examole  2.1  to  query  proces- 
sors QP5  and  QP8.  Assume  that  the  order  in  which  the  monitor  for 
the  SUPPLIER  relation  receives  reauests  is: 

NEXT_PAGE (CITYQPKT,SUPPLIER,QP5) 

NEXT_PAGE (CITYQPKT, SUPPLIER ,QP3 ) 

NEXT_PAGE (CITYQPKT, SUPPLIER ,QP5 ) 

NEXT_PAGE (CITYQPKT,SUPPLIER,QP5) 

NEXT_PAGE (CITYQPKT , SUPPLIER, QPg) 

Then,  the  pages  of  the  SUPPLIER  relation  examined  by  QP5  will  be 
1,3,  and  4 and  the  pages  of  the  SUPPLIER  relation  examined  by  QPg 
will  be  2 and  5.  Assume  that  after  the  last  NEXT_PAGE  request 
above,  the  QPA  algorithm  assigns  an  additional  query  processor 
(QP^)  to  the  CITYQPKT.  Now  there  will  be  three  query  processors 
requesting  cages  from  relation  SUPPLIER.  If  the  subsequent  re- 
quest stream  is  as  follows: 
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NEXT_PAGE (Cl TYQPKT, SUPPLIER, QP^) 

NEXT_PAGE (CITYQPKT,SUPPLIER,QP5) 

NEXT  J>  AGE (C I TYQPKT, SUPPLIER , OP ^ ) 

NEXT_PAGE (CITYQPKT, SUPPLIER, OPg) 

NEXT_PAGE (CITYQPKT,SUPPLIER,QP5) 

NEXT_PAGE (CITYQPKT, SUPPLIER, QPX) 

NEXT_PAGE (Cl TYQPKT, SUPPLIER, QPg) 

and  the  SUPPLIER  relation  consists  of  nine  Dages  then  QPl  will 
examine  Dages  6 and  8 and  then  will  receive  the  "End  of  Relation" 
(EOR)  message.  QP5  will  examine  page  7 before  receiving  an  EOR 
reply.  QP8  will  examine  page  9 before  it  receives  an  EOR  to  a 
NEXT_PAGE  request. 

By  having  a monitor  associated  with  each  entry  in  the  query 
packet  task  table  and  by  using  the  NEXT_PAGE  conceDt,  we  can 
dynamically  assign  additional  query  processor s to  a query  packet 
that  is  already  partially  executed.  In  the  case  of  a complex 
query  such  as  that  in  Figure  2.1,  it  may  be  the  case  that  the  ad- 
ditional query  processors  are  added  after  the  other  query  proces- 
sors have  finished  the  restrict  of  Rj  and  R2 . Our  approach  han- 
dles this  situation  correctly.  When  the  newly  assiqned  auery  pro- 
cessors attempt  to  restrict  R^  (or  R2) , they  will  get  "End  of  Re- 
lation" immediately  and  will  therefore  proceed  to  begin  the  join 
of  Ri ' with  R2 ’ . 

4.2  The  GET-PAGE  OPERATION 

The  form  of  the  GET^PAGE  Operation  is: 

GET_PAGE (QPKTi , REL j ,QPk,PAGEm) 

It  represents  a request  from  a query  processor  for  PAGEm  of  RELj. 
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A query  processor  which  is  executrnq  A join  B will  use  this 
operator  to  retrieve  everv  page  in  B for  each  cage  of  A it  exam- 
ines. No  monitor  is  needed  to  coordinate  GETPAGE  requests. 

4.3  PAGE  FAULTS  IN  DIRECT 

The  third  task  of  the  CCD  memory  management  process  is  to 
handle  paae  faults  by  scheduling  page  transfers  between  CCD 
memory  page  frames  and  mass  memory.  A page  fault  occurs  when  a 
requested  cage  is  not  in  some  CCD  memory  module.  In  DIRECT  these 
page  faults  will  be,  to  a large  extent,  avoidable  by  doing  anti- 
cipatory paging.  In  the  CITYQPKT  (Example  2.1),  for  example,  the 
controller  knows  that  the  entire  SUPPLIER  relation  will  be  exam- 
ined and  hence  the  reference  string  of  the  CITYQPKT  is  known  in 
advance.  By  using  the  currency  pointer  for  the  SUPPLIER  relation 
in  the  query  packet  task  table,  the  SUPPLIER  relation  paqe  table, 
and  the  current  query  processor  allocation,  the  controller  can 
determine  how  far  ahead  it  should  attempt  to  be  in  order  to  in- 
sure that  there  will  always  be  a page  ready  for  each  query  pro- 
cessor which  is  executing  the  packet. 


5.0  Relation  Fragmentation  and  Compression 

In  this  section  we  will  discuss  why  the  problem  of  relation 
fragmentation  occuis,  when  a relation  should  be  compressed,  and 
how  many  query  processors  should  be  used  to  perform  the  compress 
operation.  The  query  shown  in  Figure  2.1  will  be  used  throughout 
this  section  to  . i 1 lustr ate  several  points.  In  this  query,  rela- 
tions and  R2  are  "restricted"  by  boolean  search  conditions  to 


mm  - 
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form  R^  ' and  1*2''  respectively.  Then,  relations  1 and  R2 ' are 
"joined"  to  form  the  result  relation  R3 . 

In  the  following  sections  we  will  address  the  following 
questions: 

- Why  should  a relation  ever  be  comoressed? 

- Before  performing  the  join  operation,  should  relation  R^ ' , R2 ' , 
or  both  R^ ' and  R2 ' be  compressed? 

- How  many  query  processors  should  be  assiqned  to  compress  a re- 
lation so  that  the  execution  time  of  the  complete  query  is 
minimized? 

5.1  Relation  Fragmentation 

In  order  to  explain  the  need  for  compression,  consider  the 
restriction  of  relation  R^  in  Figure  2.1  to  form  relation  R-j.  ’ . 
If  Rj  contains  1000  pages  and  1000  query  processors  are  available 
to  execute  the  restrict  operator,  then  each  query  processor  will 
examine  one  page  of  Rj  and  will  produce  at  most  one  cage  of  R^ ’ . 

If  20%  of  the  tuples  of  R^  satisfy  the  search  criterion,  then 

each  page  of  R^ ' will,  on  the  averaqe,  be  20%  full.  If  only  500 
query  processors  are  used  to  evaluate  the  restrict  operator  then 
500  pages,  each  of  which  is  40%  full,  will  be  produced.  Note, 
however,  that  if  one  time  unit  is  the  amount  of  time  required  for 
one  query  processor  to  restrict  one  page  of  a relation,  then  the 
restrict  operator  will  require  one  time  unit  if  1000  query  pro- 
cessors are  used  and  two  time  units  if  500  processors  are  used. 

Thus,  there  is  a tradeoff  between  the  processing  time  of  an 

operation  and  the  degree  of  fragmentation  of  the  relation  pro- 
duced . 


As  another  example,  assume  that  contains  1000  pages,  that 
25%  of  the  tuples  in  R^  satisfy  the  restriction,  and  that  100 
query  processors  are  assigned  to  perform  the  restriction.  Then 
each  query  processor  will  examine  (approximately ) 10  pages  of  Rj 
and  will  produce,  on  the  avei aq°,  2.5  pages  of  Ri ' • Therefore, 
before  R^ ' is  compressed  it  will  contain  300  pages.  Two  hundred 
of  these  pages  will  be  full  and  100  will  be  50%  full. 

To  proceed  more  formally  we  need  the  following  definitions. 
Let  QP  be  the  number  of  query  processors  which  are  available  to 
execute  a query.  For  a restrict  operator  , let  RF  be  the  fraction 
of  the  tuples  that  satisfy  the  search  criteria.  Finally,  for 
each  relation,  R^ , in  the  database,  three  pieces  of  information 
are  maintained.  is  the  size  of  R ^ in  pages.  QPF^  is  the 
number  of  the  pages  that  are  only  partially  filled.  For  those 
pages  that  are  partially  filled,  F^  indicates  how  full  each  page 
is  (on  the  average).  For  our  previous  example  Sj  = 1000,  QPF^  = 
0,  Fx  = 0,  Sj*  = 300,  QPFi  ' = 100,  and  Fx ' = 0.5. 

Assume  that  QP  query  processors  are  assiqned  to  restrict  re- 
lation R ^ with  size  If  Pmax  = MOD(S^,QP)  and  Pm;n  = QP  - pmax' 


then  pmax 


processors  will  each  examine  Cmax  = 


+ 1 pages  and 


Pmin  processors  will  each  examine  Cmin  = 


l 

QP 


pages  of  R^.  The 


size  of  the  resulting  relation  R^’,  S^’,  will  be: 

t~\  + Pm;„  * rCmin  * RFil  pages. 


P * rcmax  * Rf1  i I + pmin 


' max 

QPF ^ ' will  equal: 

pmax  * ^taction  (Cmax  * RFj)!  + P 


min 


* ff  ract  ion  (Cmin  * RF^)*] 
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and  F ^ ' will  be  equal  to: 

^max  *^fracti°n (Cmax  * RFi>  + pmin  * f r act  ion (Cmin  * RPi^ 

QPFi  ' 

Finally,  if  QP  > S^,  then  only  query  processors  will  be  used 
to  perforin  the  restriction. 

5.2  The  Compress  Operator 


The  purpose  of  the  compress  operator  is  to  eliminate  rela- 
tion fragmentation  by  compressing  those  pages  of  a relation  which 
are  only  partially  full.  This  can  be  accomplished  by  reading 
partially  full  pages  and  writing  full  ones. 

If  CP  is  the  number  of  query  processors  used  to  compress  re- 
lation and  Tpt  is  the  time  reauired  to  move  a page  between  a 
query  processor's  local  memory  and  the  CCD  memory  then  the  time 
required  to  perform  the  compression  is: 


"QPFi" 

* T ..  + 

'"QPFi" 

* F< 

CP 

pr 

CP 

1 

Apr 

The  first  term  represents  the  time  required  by  the  CP  query  pro- 
cessors to  read  the  QPF^  partially  filled  oaqes  and  the  second 
term  represents  the  time  required  to  write  the  compressed  pages. 
The  size  of  the  compressed  relation  R^'  is: 


Si>  s Si  - QPFi  + MOD(QPFifCP)  * 


QPF  j 


CP 


+ 1) 


+ (CP  - MOD (QPF i , CP ) ) * 


QPFi 

CP 


As  with  the  restriction  operator,  there  is  a 
time/fragmentation  tradeoff  associated  with  the  compress  opera- 
tor. As  the  number  of  query  processors  employed  increases,  Tc, 
the  time  required  ' to  compress  the  relation,  decreases  but  the 
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value  of  S^'  increases  since  each  of  the  CP  query  processors  will 
terminate  with  a partially  filled  page.  As  we  will  demonstrate 
in  Section  5.4,  the  ODtimal  value  of  CP  cannot  be  determined 
without  examining  how  the  compressed  relation  is  used  by  subse- 
quent ODerations  in  the  querv. 

5.3  Employment  of  the  Compress  Operator 

Consider  the  query  shown  in  Figure  2.1.  Since  both  ' and 
R2 ' contain  partially  filled  Dages  and  since  the  execution  time 
of  the  join  is  proportional  to  the  product  of  the  sizes  of  the 
two  source  relations,  the  obvious  choice  is  to  compress  both  re- 
lations before  performing  the  join.  The  modified  query  tree 
representing  this  choice  is  shown  in  Figure  5.1.  ^s  we  will  now 
demonstrate,  compressing  R^ 1 will  actually  increase  the  execution 
time  of  the  query. 


JOIN 


COMPRESS 


COMPRESS 


RESTRICT 


RESTRICT 


Figure  5.1 


To  understand  why  this  is  true,  we  must  examine  how  DIRECT 
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executes  a join  operation.  If  the  number  of  query  processors  as- 
signed to  execute  the  join  in  Figure  5.1  is  equal  to  the  size  of 
R^"  (i.e.  QP  = S^")  then  each  query  processor  will  read  one  page 
of  Ri".  It  will  then  attempt  to  join  the  tuples  on  its  page  of 
R^ " with  all  the  tuples  in  R2"  by  reading  R2"  one  oage  at  a time. 

There  are  several  alternative  reasons  why  compressing  R^ ' 
will  increase  the  execution  time  of  the  join  operation.  If 
QPsS^',  then  compresssing  R^ ' will  reduce  the  number  of  query 
processors  which  can  be  utilized  to  execute  the  join  operation 
from  Sj  ' to  S-l  " . Furthermore,  since  compression  does  not  reduce 
the  number  of  tuples  in  a relation,  each  of  the  S^"  query  proces- 
sors will  have  to  examine  more  tuples  from  relation  R^".  There- 
fore, each  query  processor  will  produce  a greater  percentage  of 
R3.  This  will  result  in  more  page  writes  per  query  processor  and 
hence  increased  processing  time  for  the  complete  query. 

If  QP  <<  S^"  (the  size  of  the  compressed  relation),  the 
above  argument  will  no  longer  be  valid.  Rather,  if  Rj ' is 
compressed,  then  since  S^"  < S ^ * the  time  spent  by  each  query 
processor  reading  pages  of  R2"  will  be  reduced: 


fl" 

QP 


b2  apr  < 


V 

QP 


* q _ " * t 
b2  1 pr • 


If  CP  query  processors  are  assigned  to  compress  R^ ' before  the 

'QPPi ’ 


join  operation,  then 


CP 


* Tpt  seconds  will  be  used 


to  read  the  partially  filled  oages.  Additional  time  will  also  be 
required  to  write  the  compressed  oages  and  then  reread  the  pages 
of  Rj"  to  perform  the  join. 

An  alternative  approach  is  to  make  the  compression  of  Rj ' an 
implicit  component  of  the  join.  By  having  each  of  the  QP  query 
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processors  attempt  to  read  enough  partially  filled  Dages  of  ' 
to  fill  its  buffer  before  oroceeding  to  read  the  first  cage  of 
R2"*  the  compression  will,  in  effect,  be  performed  in  only 


QPF!  1 


* TDr  seconds. 


If  QP  = ' = QPF^ ' , then  each  query  processor  will  fail  in  its 
attemot  to  fill  its  buffer.  It  will,  therefore,  proceed  to  join 
a partially  filled  buffer  containing  tuples  of  ' with  all  the 
tuples  in  **2"'  5Y  using  this  approach  we  achieve  the  best  as- 
pects of  both  approaches.  We  do  not  limit  the  potential  con- 
currency when  QP  = ' and  yet  we  will  achieve  the  performance 
improvement  of  compression  when  QP  <<  S^". 

While  explicit  compression  of  R^ ’ is  not  beneficial, 
compression  of  R2 ' certainly  will  be.  Since  each  query  procesor 
will,  for  each  page  of  R^ ' it  examines,  read  a_ll  of  R2 ' ' 
compression  of  R2 ' will  significantly  reduce  the  number  of  page 
reads  performed  and  hence  the  execution  time  of  the  query.  There 
is,  however,  a tradeoff  between  the  benefits  obtained  by  doinq 
compression  versus  the  cost  of  performing  the  compression.  In 
the  following  section,  we  will  develop  a method  for  choosing  the 
value  of  CP  so  as  to  minimize  the  cost  of  performing  the  compres- 
sion while  maximizing  the  resulting  benefits. 

5.4  Calculation  of  the  Optimal  Value  of  CP 

As  discussed  in  Section  5.2,  there  is  a tradeoff  between 
minimizing  the  time  required  to  perform  a compression,  Tc,  and 
the  size,  S^',  of  the  compressed  relation.  As  the  value  of  CP 
incieases,  Tc  will  decrease  but  S ^ ' will  increase.  Since  the 
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compressed  relation  is  subsequently  used  as  an  operand  in  a join 
(R2"  in  Figure  5.1),  any  increase  in  the  value  of  S^'  will  also 
increase  the  execution  time  of  the  join.  In  this  section  we  will 
develop  a formula  for  detei mining  the  value  of  CP  such  that  the 
execution  time  of  the  compress  and  join  operations  is  minimized. 

In  Section  5.2,  exoressions  for  Tc  and  S^'  were  developed. 
The  time  to  execute  the  join,  Tj  , is  expressed  by: 

T • = T + T + T 

Aj  Ar  e w 

Tg  represents  the  time  required  to  join  tuoles  of  the  two  source 
relations  and  is  independent  of  the  number  of  pages  in  relations 
R^  ' and  R2"  (S^  ' and  S2"  respectively).  The  time  required  by  the 
query  processors  to  move  pages  of  the  result  relation  from  local 
memory  to  a CCD  memory  module  is  T . Tw  depends  only  the  number 
of  tuples  produced  by  the  join  and  QP,  the  number  of  query  pro- 
cessors used  to  execute  the  join.  Tr , the  time  spent  reading 
pages  of  the  two  source  relations  can  be  expressed  as: 


T = 
Ar 


1 

- 1 

1 — 1 1 
V)  1 

1 

* T + 

QP 

pr 

QP 

* * T 

b2  xpr 


Since  Tg  and  Tw  are  independent  of  ' and  S2"  and  since 


V 

QP 


* T 

pr 


is  not  effected  by  the  compress  operator,  Tj  can  be  rewritten  as: 


Tj  - 


V 

QP 


* C »•  * rn  + r 

b2  ipr  + c 


The  time  required  to  execute  both  the  compress  and  the  join,  T = 
Tc  + Tj,  is  thus: 


T = 


■qpf2’" 

1r  m , 

'■qpf2’1 

* p 1 

* T 4. 

CP 

Tpr  + 

CP 

2 

Tpr  + 

QP 

* C '•  * T +1- 

b2  xpr  * c 


Since  the  result  of  the  comptession  is  to  reduce  the  size  of  re- 


lation R2'  from  S2 ’ to  S2 " f we  can  substitute  the  expression  for 


This  yields: 


S2"  developed  in  Section  5.2  and  divide  by  T 


pr  ■ 


T = 


Qp*y 

CP 


qpf2' 

CP 


* F2' 


pr] 

r 

QPF?  ' 

QP 

* (S2 ' - QPF2’  + MOD (QPF2 ' ,CP)  * 

( 

CP 

+ 1)  * f9  ’ 


+ (CP  - MOD (QPF2  ' ,CP)  ) 


QpF2  ' 
CP 


P2' 


) + c- 


T can  be  simpified  further  by  consolidating  those  terms  which  are 
independent  of  CP  into  c.  This  simplification  yields: 


qpf2  • 1 

' 

"qpf2'1  “ 

T = 

CP  ! 

+ 

j * f2 ■ 

CP  I 

"V' 

Qpf2  ' 

QP 

* (MOD(QPF2 ' ,CP)  * 

( 

CP 

+ l)  * F2' 

+ (CP  - MOD (QPF2 ’ ,CP) ) * 


qpf2’ 

CP 


) + c- 


The  obvious  approach  of  differentiating  T with  respect  to  CP 
to  find  that  value  of  CP  which  minimizes  T will  not  work  since 
this  function  is  not  continuous.  We  have  plotted  T,  Tc  (the 
first  two  terms  of  T)  , and  Tt ^ (the  third  term  of  T)  as  functions 
of  CP  in  Figures  5.2  and  and  5.3  for  two  different  sets  of  data. 

As  is  illustrated  by  Figures  5.2  and  5.3,  Tc  is  a nonin- 
creasing step  function  of  CP.  Thus,  CPj  > CPj  implies  Tc(CPj) 
< Tc  (CP  j.  ) . Tr  -j , on  the  othethand,  remains  relatively  constant 
(with  minor  fluctuations)  until  a certain  value  of  CP,  CPm,  is 
reached.  At  CP=CPm,  T,.j  begins  to  increase  as  a linear  function 
of  CP  until  CP  becomes  equal  to  QPF2 ' . At  this  point,  and  for 
all  values  of  CP  > QPF2',  compression  will  have  no  effect  since 
each  of  the  CP  mocessors  will  read  exactly  one  page  of  R2'. 


An  obvious  choice  for  that  value  of  CP  which  may  perhaos 


minimize  T is  CPm.  While  values  of  CP  less  than  CPm  may  produce 
values  of  Trj  less  than  the  value  of  Tt j at  CPm,  the  decrease  in 
Trj  is  more  than  offset  bv  a large  increase  in  Tc.  We  can  deter- 


mine a formula  to  calculate  CPm,  by  first  observing  what  changes 


occur  in  Trj  at  CPm. 


Starting  with  CP=1,  as  more  and  more  query  processors  are 
used  to  compress  a relation,  the  maximum  number  of  pages  of  the 
compressed  relation  produced  by  any  one  orocessor  decreases.  For 
a given  value  of  CP,  this  number  is  expressed  by: 


-QpF2,_ 

CP 

* F2’ 


As  long  as  CP  is  ,]ogs  than  by  QPF2 ' , the  minimum  value  of  this 
expression  is  f2  * F2'^-  Thus,  when  F21  < 0.5,  T 2 * F2  * ~ ! is 
equal  to  1.  Otherwise,  when  F2 ' > 0.5,  it  is  equal  to  2.  The 
first  value  of  CP  such  that 


-QPF2  1 

CP 

* F2  ' 


equals  1 if  F21  £ .5  or  2 if  F2 ' > .5  will  be  CPm.  As  CP  grows 
larger  than  CPm,  the  maximum  number  of  pages  produced  by  any  one 
processor  will  continue  to  equal  to  1 (or  2) . Thus,  Sc  (the  size 
of  the  compressed  relation)  and  hence  Tr^  will  grow  as  a linear- 
function  of  CP  (with  slope  of  1 or  2 depending  of  the  value  of 
F2 ' ) until  CP  becomes  equal  to  QPF2 ' • At  this  point  Sc  will  be- 
come equal  to  QPF21. 


Solving 


-QPFy' 

CP 

* F2 ' 


= n , n=l , 2 
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T” 


I 


for  CP  yields:  CP  = 


Qpv 

n 

L V-J 

If  F2 ' is  less  than  0.5,  then  evaluating  this  expression  with  n 
equal  to  1 will  yield  the  correct  value  of  CPm.  Otherwise,  it 
should  be  evaluated  with  n equal  to  2. 

For  QPF21  = 22and  F2'  = 0.30,  evaluation  of  the  formula  for 
CP  yields  CP  = 8.  As  indicated  in  Figure  5.2,  this  is  the 
correct  value  for  CPm  and  is  also  the  value  of  CP  that  minimizes 
T.  The  expression  for  CP  also  gives  the  correct  value  for  the 
example  shown  in  Figure  5.4. 

The  expression  for  CP  can  also  be  used  to  determine  whether 


compression  of 


will  be  beneficial  in  terms  of  reducing  the 


time  to  execute  the  join. 


For  example,  assume  that  QP=50, 


S^'^SO,  QPF2 ' =22 , and  F2 1 = 0.826.  Plotting  T as  a function  of 
CP  for  this  example  indicates  that  the  minimum  value  of  T occurs 
when  CP=22.  Evaluation  of  the  expression  above  yields  CPm=ll. 
Since  F2*  is  greater  than  0.5,  each  of  the  11  processors  will 
produce  two  pages  of  the  compressed  relation.  Therefore,  the 
size  of  the  compressed  relation  will  be  22  and  hence  it  is  not 
worthwhile  to  perform  the  compression. 

CPm  will  not,  however,  always  give  an  accurate  estimate  of 
that  value  of  CP  which  will  minimize  T.  For  example,  if  QP  = 50, 
QPF2'  = 22,  S-^ ' = 50,  and  F2 ' ® 0.0826,  the  value  of  CPm  which  is 
computed  is  2.  The  minimum  value  of  T,  however,  occurs  when  CP  = 
4.  This  situation  arises  because  Tc  is  the  dominating  term  in  T. 
If  Sj 1 equaled  150  instead  of  50,  then  CPm  would  have  indeed  been 


the  value  of  CP  which  minimized  T. 


Therefore,  by  evaluating  CP  - 


QPF2' 


the  optimal  number  of  query  processors  to  perform  the  comoression 
can  be  estimated.  If  F2'  is  less  than  or  equal  to  0.5,  this  ex- 
pression should  be  evaluated  with  n equal  to  1.  Otherwise,  it 
should  be  evaluated  with  n equal  to  2.  If  F2  ' * 0.5,  then 
compression  will  be  worthwhile  if  and  only  if  CPm  * 2 is  less 
than  QPF2 ' . While  CPm  may  not  always  be  the  value  of  CP  which 
minimizes  T,  it  appears  to  generally  be  a very  good  estimate  of 
it.  Furthermore,  as  is  indicated  by  Figures  5.2  and  5.3, 
compression  of  R2 ' using  CPm  Drocessors  significantly  reduces  the 
execution  time  T when  compared  to  the  execution  time  of  the  query 
when  R2 ' is  not  compressed  (i.e.  the  value  of  T when  CP  = QPF2 ’ ) . 


6.0  Conclusions 

In  this  paper  we  have  discussed  query  organization,  execu- 
tion, and  optimization  in  DIRECT.  The  use  of  a monitor  for  each 
relation  referenced  by  a query  along  with  the  use  of  the 
NEXT_PAGE  construct  permits  the  DIRECT  back-end  controller  to  as- 
sign a query  to  any  number  of  processors  for  execution.  Further- 
more, these  constructs  also  permit  the  controller  to  balance  the 
load  in  the  back-end  by  dynamically  adjusting  how  many  processors 
are  assigned  to  each  executing  query. 

We  have  also  identified  the  problem  of  relation  fragmenta- 
tion which  occurs  when  queries  are  executed  in  parallel  and 
developed  a technique  for  estimating  the  optimal  number  of  pro- 


cessors  to  compress  a r 
entire  query  is  minimiz 
to  all  database  machine 
niques  to  enhance  query 


elation  so  that  the  execution  time  of  the 
ed.  These  results  appear  to  be  applicable 
s which  employ  parallel  processing  tech- 
execution  . 
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